An enterprise system may be made up of many different applications such as customer relationships management (CRM) application, billing application, human resources application, supply chain application, etc. These applications typically need to access one another's resources. As used herein, the term “resource” refers to a function, an operation, or a data object in the system; the function or operation may also access data objects stored in a database system.
Different applications in the same system may implement different access control logic to their respective resources. Under these approaches, if an access control policy is to be added, deleted, or modified in an application, source code for corresponding access control logic must be modified and re-compiled.
An application developer defines application-specific privileges to protect its functions or operations. These privileges are defined and managed independently by each application in its own local-scope. Increasingly there are use cases when applications execute each other's operations in enterprise settings resulting in sharing of privilege definitions and administration of shared operations. In such cases, application developers face the challenge to uniformly define privileges, i.e., with a common understanding of privilege semantics, to protect application functions with an enterprise-wide policy in the global scope.
Under some other approaches, access control policies for resources may be declaratively defined in an enterprise-wide access control list (ACL). Based on the enterprise-wide ACL, access control logic in the system may determine whether any requesting subject has any privilege to access a particular resource. However, it is difficult to define a single enterprise-wide ACL for all the applications in the enterprise system, as these applications may implement different semantics for access control based on different computing products by different development organizations. Even if it is possible to set up a single enterprise-wide ACL in a consistent way, it may be extremely complex and difficult to maintain. For example, coordinating changes to a single global file by various security administrators responsible for different parts of the system is difficult to do in practice.
Furthermore, a single enterprise-wide ACL would take a long time to load at runtime. When a minor change is made to the enterprise-wide ACL, cache entries stored in the system memory may require reloading of a large number of entries in the enterprise-wide ACL, in order to ensure integrity and coherency of all the entries from the single file. This reloading may occur often as minor changes are being made to the single enterprise-wide ACL for various applications.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.